Frontend API Gateway: GraphQL Федерация и Schema Stitching

В света на модерната разработка на уеб приложения, управлението на данни от множество източници може да бъде значително предизвикателство. С нарастването на сложността на приложенията и възприемането на архитектури с микроуслуги, необходимостта от унифициран и ефективен начин за достъп до данни става първостепенна. Frontend API Gateway действа като централна входна точка за клиентските приложения, като агрегира данни от различни бекенд услуги и предоставя оптимизирано изживяване както за разработчиците, така и за крайните потребители. Тази блог публикация изследва две мощни техники за изграждане на Frontend API Gateway: GraphQL Федерация и Schema Stitching.

Какво е Frontend API Gateway?

Frontend API Gateway е архитектурен модел, при който специален сървър действа като посредник между клиентските приложения (напр. уеб браузъри, мобилни приложения) и множество бекенд услуги. Той опростява извличането на данни чрез:

• Агрегиране на данни: Комбиниране на данни от множество източници в един отговор.
• Трансформиране на данни: Адаптиране на форматите на данните, за да отговарят на нуждите на фронтенда.
• Абстрахиране на сложността: Скриване на сложността на бекенд услугите от клиента.
• Налагане на сигурност: Имплементиране на политики за автентикация и оторизация.
• Оптимизиране на производителността: Кеширане на често достъпвани данни и намаляване на мрежовите заявки.

По същество той прилага модела Backend for Frontend (BFF) в голям мащаб и дава възможност на фронтенд екипите да поемат по-голям контрол върху API-тата, които консумират. В по-големи организации, когато фронтендът управлява и поддържа свои собствени API-та, това може да доведе до по-бърза доставка и намалена зависимост от бекенд екипите.

Защо да използваме GraphQL за Frontend API Gateway?

GraphQL е език за заявки за API-та и среда за изпълнение на тези заявки с вашите съществуващи данни. Той предлага няколко предимства пред традиционните REST API-та, което го прави много подходящ за изграждане на Frontend API Gateway:

• Ефективно извличане на данни: Клиентите изискват само данните, от които се нуждаят, което намалява прекомерното извличане (over-fetching) и подобрява производителността.
• Силно типизиране: GraphQL схемите дефинират структурата на данните, което позволява по-добри инструменти и валидация.
• Интроспекция: Клиентите могат да открият наличните данни и операции чрез интроспекция на схемата.
• Възможности в реално време: GraphQL абонаментите (subscriptions) позволяват актуализации на данни в реално време.

Като използва GraphQL, един Frontend API Gateway може да предостави гъвкав, ефективен и удобен за разработчиците интерфейс за достъп до данни от множество бекенд услуги. Това е в рязък контраст с традиционните подходи, използващи множество REST крайни точки, всяка от които трябва да бъде заявена индивидуално и често връща повече данни от необходимото.

GraphQL Федерация: Разпределен подход

Какво е GraphQL Федерация?

GraphQL Федерацията е мощна техника за изграждане на разпределено GraphQL API чрез композиране на множество GraphQL услуги (наречени "подграфи") в една единна, обединена схема. Всеки подграф е отговорен за конкретен домейн или източник на данни, а Federation gateway оркестрира заявките между тези подграфи.

Основната концепция се върти около суперграф, една единна, обединена GraphQL схема, която представлява цялото API. Този суперграф се изгражда чрез композиране на по-малки GraphQL схеми, наречени подграфи, всеки от които представлява конкретна микроуслуга или източник на данни. Federation gateway е отговорен за маршрутизирането на входящите GraphQL заявки към съответните подграфи и комбинирането на резултатите в един отговор.

Как работи GraphQL Федерацията

1. Дефиниция на подграф: Всяка микроуслуга предоставя GraphQL API (подграф), който дефинира собствените си данни и операции. Тези схеми включват директиви, които казват на Federation gateway как да разрешава типове и полета. Ключови директиви включват `@key`, `@external` и `@requires`.
2. Композиция на суперграф: Federation gateway (напр. Apollo Gateway) извлича схемите от всеки подграф и ги композира в една единна, обединена схема (суперграфа). Този процес включва разрешаване на конфликти между типове и полета и установяване на връзки между типове от различни подграфи.
3. Планиране и изпълнение на заявка: Когато клиент изпрати GraphQL заявка към gateway, той анализира заявката и определя кои подграфи трябва да бъдат заявени, за да се изпълни заявката. След това разпределя заявката към съответните подграфи, събира резултатите и ги комбинира в един отговор, който се връща на клиента.

Пример: Платформа за електронна търговия с GraphQL Федерация

Да разгледаме платформа за електронна търговия с отделни микроуслуги за продукти, клиенти и поръчки.

• Подграф за продукти: Управлява информация за продуктите (име, описание, цена и т.н.).
• Подграф за клиенти: Управлява данни за клиентите (име, адрес, имейл и т.н.).
• Подграф за поръчки: Управлява информация за поръчките (ID на поръчка, ID на клиент, ID на продукти, обща сума и т.н.).

Всеки подграф предоставя GraphQL API, а Federation gateway композира тези API-та в един-единствен суперграф. След това клиентът може да направи заявка към суперграфа, за да извлече информация за продукти, клиенти и поръчки в една-единствена заявка.

Например, заявка за извличане на името на клиент и историята на поръчките му може да изглежда така:

query GetCustomerAndOrders($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    orders {
      id
      orderDate
      totalAmount
    }
  }
}

Federation gateway ще пренасочи тази заявка към подграфите за клиенти и поръчки, ще извлече необходимите данни и ще ги комбинира в един-единствен отговор.

Предимства на GraphQL Федерацията

• Опростен достъп до данни: Клиентите взаимодействат с една-единствена GraphQL крайна точка, независимо от базовите източници на данни.
• Подобрена производителност: Извличането на данни е оптимизирано чрез извличане само на необходимите данни от всеки подграф.
• Повишена мащабируемост: Всеки подграф може да се мащабира независимо, което позволява по-добро използване на ресурсите.
• Децентрализирана разработка: Екипите могат да разработват и внедряват подграфи независимо, насърчавайки гъвкавост и иновации.
• Управление на схемата (Schema governance): Federation gateway налага последователност и съвместимост на схемите между подграфите.

Инструменти за GraphQL Федерация

• Apollo Federation: Популярна реализация на GraphQL Федерацията с отворен код, предоставяща gateway, регистър на схеми и инструменти за изграждане и управление на федеративни GraphQL API-та. Apollo Federation е известна със своята мащабируемост и надеждна обработка на грешки.
• GraphQL Hive: Този инструмент предлага регистър на схеми и управление за GraphQL федеративни услуги, предоставяйки функции като откриване на промени, анализ на употребата и проверки на схемата. Той подобрява видимостта и контрола върху суперграфа.

Schema Stitching: Алтернативен подход

Какво е Schema Stitching?

Schema Stitching е друга техника за комбиниране на множество GraphQL схеми в една единна, обединена схема. За разлика от Федерацията, Schema Stitching обикновено включва по-ръчен процес на дефиниране как типовете и полетата от различни схеми са свързани. Докато Федерацията се счита за по-модерно и стабилно решение, Schema Stitching може да бъде жизнеспособна опция за по-прости случаи на употреба или при миграция от съществуващи GraphQL API-та.

Как работи Schema Stitching

1. Дефиниция на схема: Всяка микроуслуга предоставя GraphQL API със собствена схема.
2. Логика за свързване (Stitching Logic): Слой за свързване (често имплементиран с библиотеки като GraphQL Tools) дефинира как типовете и полетата от различни схеми са свързани. Това включва писане на resolver функции, които извличат данни от базовите услуги и ги съпоставят с обединената схема.
3. Обединена схема: Слоят за свързване комбинира индивидуалните схеми в една единна, обединена схема, която се предоставя на клиента.

Пример: Свързване на продукти и ревюта

Представете си две отделни GraphQL услуги: една за продукти и друга за ревюта.

• Услуга за продукти: Предоставя информация за продукти (ID, име, описание, цена).
• Услуга за ревюта: Предоставя ревюта за продукти (ID, ID на продукт, рейтинг, коментар).

Използвайки Schema Stitching, можете да създадете обединена схема, която позволява на клиентите да извличат информация за продукти и ревюта в една-единствена заявка.

Ще трябва да дефинирате resolver функция в слоя за свързване (stitching layer), която извлича ревюта за даден продуктов ID от услугата за ревюта и ги добавя към типа Product в обединената схема.

// Пример (концептуален): Логика за свързване с GraphQL Tools
const { stitchSchemas } = require('@graphql-tools/stitch');

const productsSchema = ... // Дефинирайте вашата схема за продукти
const reviewsSchema = ... // Дефинирайте вашата схема за ревюта

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: productsSchema,
    },
    {
      schema: reviewsSchema,
      transforms: [
        {
          transformSchema: (schema) => schema,
          transformRequest: (originalRequest) => {
            return originalRequest;
          },
          transformResult: (originalResult) => {
            return originalResult;
          }
        }
      ],
    },
  ],
  typeDefs: `
    extend type Product {
      reviews: [Review]
    }
  `,
  resolvers: {
    Product: {
      reviews: {
        resolve: (product, args, context, info) => {
          // Извличане на ревюта за продукта от услугата за ревюта
          return fetchReviewsForProduct(product.id);
        },
      },
    },
  },
});

Този пример демонстрира основната концепция за свързване на схеми. Обърнете внимание на нуждата от персонализирани резолвери за извличане на полето `reviews`. Тази допълнителна работа по кодиране на резолвери за всяка връзка може да направи процеса на разработка по-бавен в сравнение с използването на Федерация.

Предимства на Schema Stitching

• Обединено API: Клиентите достъпват една-единствена GraphQL крайна точка, което опростява достъпа до данни.
• Постепенно възприемане: Schema Stitching може да се имплементира постепенно, което ви позволява плавно да мигрирате към обединено API.
• Гъвкавост: Schema Stitching предоставя повече контрол върху начина, по който се комбинират схемите, което ви позволява да персонализирате логиката за свързване, за да отговори на конкретни нужди.

Недостатъци на Schema Stitching

• Ръчна конфигурация: Schema Stitching изисква ръчна конфигурация на логиката за свързване, което може да бъде сложно и отнемащо време.
• Натоварване на производителността: Resolver функциите могат да въведат допълнително натоварване на производителността, особено ако включват сложни трансформации на данни.
• Ограничена мащабируемост: Schema Stitching може да бъде по-трудно за мащабиране от Федерацията, тъй като логиката за свързване обикновено е централизирана.
• Собственост на схемата: Може да доведе до неяснота относно собствеността на схемата, особено ако различни екипи управляват свързаните услуги.

Инструменти за Schema Stitching

• GraphQL Tools: Популярна библиотека за изграждане и манипулиране на GraphQL схеми, включително поддръжка за Schema Stitching.
• GraphQL Mesh: GraphQL Mesh ви позволява да използвате езика за заявки GraphQL за достъп до данни от различни източници като REST API-та, бази данни и gRPC. Той може да свърже тези API-та в обединена GraphQL схема.

GraphQL Федерация срещу Schema Stitching: Сравнение

Както GraphQL Федерацията, така и Schema Stitching предлагат начини за комбиниране на множество GraphQL схеми в едно API, но се различават по своя подход и възможности.

Характеристика	GraphQL Федерация	Schema Stitching
Подход	Разпределена, автоматизирана композиция	Централизирана, ръчна конфигурация
Сложност	По-ниска сложност за поддръжка и мащабиране	По-висока сложност поради ръчната логика на резолверите
Мащабируемост	Проектирана за големи, разпределени системи	По-малко мащабируема, обикновено се използва за по-малки приложения
Управление на схемата	Вградено управление и валидация на схемата	Изисква ръчно управление и координация на схемата
Инструменти	Силна екосистема от инструменти и библиотеки (напр. Apollo Federation)	Изисква повече персонализирани инструменти и конфигурация
Случаи на употреба	Архитектури с микроуслуги, големи API-та, децентрализирана разработка	По-малки приложения, постепенна миграция, специфични изисквания за персонализация

Кога да използвате GraphQL Федерация: Изберете Федерация, когато имате сложна архитектура с микроуслуги, трябва да мащабирате своето API и искате да дадете възможност на независими екипи да управляват собствените си подграфи. Тя също така опростява управлението и контрола на схемата.

Кога да използвате Schema Stitching: Обмислете Schema Stitching, когато имате по-просто API, нуждаете се от повече контрол върху логиката за свързване или мигрирате от съществуващи GraphQL API-та. Въпреки това, имайте предвид потенциалните сложности и ограничения в мащабируемостта.

Имплементиране на автентикация и оторизация

Независимо дали ще изберете GraphQL Федерация или Schema Stitching, имплементирането на автентикация и оторизация е от решаващо значение за защитата на вашия Frontend API Gateway. Има няколко подхода, които можете да предприемете:

• Автентикация на ниво gateway: API Gateway се занимава с автентикацията и оторизацията преди да пренасочи заявките към бекенд услугите. Този подход централизира логиката за сигурност и опростява бекенд услугите. Често срещани методи включват валидация на JWT (JSON Web Token) и OAuth 2.0.
• Автентикация на ниво услуга: Всяка бекенд услуга се занимава със собствената си автентикация и оторизация. Този подход предоставя по-детайлен контрол върху сигурността, но може да бъде по-сложен за управление.
• Хибриден подход: Комбинация от автентикация на ниво gateway и на ниво услуга. Gateway се занимава с първоначалната автентикация, а бекенд услугите извършват по-детайлни проверки за оторизация.

Пример: JWT автентикация с Apollo Federation

С Apollo Federation можете да конфигурирате gateway да валидира JWT токени, включени в хедърите на заявката. След това gateway може да предаде потребителската информация, извлечена от токена, на подграфите, които могат да използват тази информация за оторизация.

// Пример (концептуален): Конфигурация на Apollo Gateway с JWT валидация
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    // ... вашите конфигурации на подграфи
  ],
  buildService: ({ name, url }) => {
    return new MyCustomService({
      name,  // Име на подграфа
      url,   // URL на подграфа
    });
  },
});

class MyCustomService extends RemoteGraphQLDataSource {
  willSendRequest({ request, context }) {
    // Вземане на потребителя от контекста
    const user = context.user;

    // Добавяне на ID-то на потребителя към хедърите на заявката
    if (user) {
      request.http.headers.set('user-id', user.id);
    }
  }
}

В този пример се създава персонализирана услуга за промяна на изходящите заявки, така че да включват потребителския ID, извлечен от JWT. Услугите надолу по веригата могат да използват този ID за проверки за оторизация.

Стратегии за кеширане за оптимизация на производителността

Кеширането е от съществено значение за подобряване на производителността на Frontend API Gateway. Като кеширате често достъпвани данни, можете да намалите натоварването на бекенд услугите и да подобрите времето за отговор на клиентите. Ето някои стратегии за кеширане:

• HTTP кеширане: Използвайте HTTP механизми за кеширане (напр. `Cache-Control` хедъри), за да кеширате отговори в браузъра и междинните проксита.
• Кеширане в паметта (In-Memory Caching): Използвайте кешове в паметта (напр. Redis, Memcached), за да кеширате често достъпвани данни на gateway.
• CDN кеширане: Използвайте мрежи за доставка на съдържание (CDN), за да кеширате статични активи и API отговори по-близо до клиента.
• Кеширане на GraphQL заявки: Кеширайте резултатите от GraphQL заявките въз основа на техния низ на заявката и променливи. Това може да бъде особено ефективно за често изпълнявани заявки. Apollo Server предлага вградена поддръжка за кеширане на заявки.

Когато прилагате кеширане, обмислете стратегии за инвалидиране на кеша, за да сте сигурни, че клиентите получават актуални данни. Често срещаните стратегии включват:

• Изтичане на базата на време: Задайте фиксирано време за изтичане на кешираните данни.
• Инвалидиране на базата на събитие: Инвалидирайте кеша, когато данните се променят в бекенд услугите. Това може да се постигне с помощта на уебкуки (webhooks) или опашки за съобщения.

Мониторинг и наблюдаемост (Observability)

Мониторингът и наблюдаемостта са критични за осигуряване на здравето и производителността на вашия Frontend API Gateway. Внедрете цялостен мониторинг, за да следите ключови метрики като:

• Латентност на заявките: Времето, необходимо за обработка на заявка.
• Процент на грешките: Процентът на заявките, които водят до грешки.
• Пропускателна способност: Броят на обработените заявки за единица време.
• Използване на ресурси: Използване на CPU, памет и мрежа от gateway и бекенд услугите.

Използвайте проследяване (tracing), за да следите заявките, докато преминават през системата, идентифицирайки тесни места и проблеми с производителността. Логирането предоставя ценна информация за поведението на gateway и бекенд услугите.

Инструментите за мониторинг и наблюдаемост включват:

• Prometheus: Система за мониторинг и алармиране с отворен код.
• Grafana: Инструмент за визуализация на данни и мониторинг.
• Jaeger: Система за разпределено проследяване с отворен код.
• Datadog: Платформа за мониторинг и сигурност за облачни приложения.
• New Relic: Платформа за дигитална интелигентност за мониторинг и подобряване на производителността на софтуера.

Чрез внедряване на стабилен мониторинг и наблюдаемост можете проактивно да идентифицирате и решавате проблеми, гарантирайки надеждността и производителността на вашия Frontend API Gateway.

Заключение

Frontend API Gateway, изграден с GraphQL Федерация или Schema Stitching, може значително да опрости достъпа до данни, да подобри производителността и да подобри изживяването на разработчиците в съвременните уеб приложения. GraphQL Федерацията предоставя мощно и мащабируемо решение за композиране на разпределени GraphQL API-та, докато Schema Stitching предлага по-гъвкав подход за комбиниране на съществуващи схеми. Като внимателно обмислите специфичните изисквания на вашето приложение и компромисите между тези техники, можете да изберете най-добрия подход за изграждане на стабилен и ефективен Frontend API Gateway.

Не забравяйте да внедрите правилна автентикация и оторизация, стратегии за кеширане и мониторинг и наблюдаемост, за да осигурите сигурността, производителността и надеждността на вашия gateway. Възприемайки тези най-добри практики, можете да отключите пълния потенциал на GraphQL и да изградите модерни уеб приложения, които предоставят изключително потребителско изживяване.